Subject: RE Chen's note

From: "Hildebrand, Jeff" <[email-masked]>
Date: Tue, 01 Mar 94 18:29:00 PST

Chen,  hope this answers the questions on your last note.
Thanks,
Jeff

Initialization Data.
I have checked both protocols and have found initialization
data to be a user option.  This means that the all the
vendor must do is apply the encode/decode routine to the
buffer holding the data.  Access to this data is a local
implementation issue.

Definition: A map routine services all the encode/decode
requests for an application program.  The routine contains a
subroutine to handle each data structure to be encoded or
decoded and assigns a local MAP_NAME to each of these data
structures.

Sample scenario:

A user wants to write an application which communicates with
a service on the network (partner program).  The programmer
looks in a catalogue (an X.500 directory would make a good
catalogue) to find the name of the required routine and
where to get it.  The routine's  documentation, also stored
in the catalogue, will provide a copy book for the
input/output data structures the routine expects.  These
data structures will be in the appropriate language.  You
could have three versions of the same routine, one for
COBOL, C, and FORTRAN.  Each data structure will have a
MAP_NAME associated with it.

To send data the programmer simply:
     1.Fills in the appropriate data structure.

     2.Sets the MAP_NAME to the map name associated with the
            data structure, via the SET MAP_NAME call.

     3. Issues a send data, or allocate with initialization
     data.

To receive data
    1. The map routine simply:
     A.Receives the data record from the network.
     B.Applies the correct decode routine, identified by:
         1. LU 6.2 uses the MAP_NAME LU 6.2 variable.
          2. OSI uses the self defining nature of ASN.1.
     C.Sets the MAP_NAME to appropriate local map name.
    2. The application program:
     A.Issues an EXTRACT MAP_NAME to retrieve the map name.
     B.The program goes to the part of the application logic
         that handles the data structure associated with the  MAP_NAME.

Mapped conversation requirements from three view points.

User view:
The application programmer has a need to use a service
located somewhere on the network and looks in a catalogue,
either paper or electronic (X.500), to find it.  The
catalogue entry provides:

1.   Appropriate addressing information for the CRM.  The
OSI TP CRM might give both the application context and
the application process the partner could be found on.
The LU 6.2 CRM might only provide a transaction
program name.

2.   Entries for each supported language, e.g. COBOL, C,
and a 4GL.  These entries provide the internal data
structures the programmer should use along with the
map name associated with each of them, and the library
where the encode/decode routine can be found.
All the applications programmer sees is a routine stored in
some library that he must link to, in a fashion consistent
with the vendors product, and the data structures his
program must use.  Sending data only requires the
application to fill in the appropriate data structure and
inform the system by setting the MAP_NAME.  Receiving data
is just as easy, the program extracts the MAP_NAME to learn
what data structure contains the data.

Map routine creation view:
The creation of a map routine requires knowledge of the
encoding method and how data is represented in the target
programming language.  The user responsible for writing
these routines knows what the underlying encoding methods
are, ASN.1 or EBDIC, and writes a routine to encode a local
data structure to the format to be transmitted over the
network, and/or to decode what comes over the network.

The programmer expects the vendor to supply:

1.For the LU 6.2 CRM access to the LU 6.2 send/receive
services, PIP data variables, and LU 6.2 MAP_NAME
variable.

2.For the OSI CRM access to the TP-DATA service and TP-
BEGIN-DIALOGUE user data parameter.

Vendor view
Supporting mapped conversations requires a vendor to
provide:
1.Default map mechanism.  The LU 6.2 CRM supplier would
provide the same map mechanism that is standard with
CPIC 1.0 implementations.  The OSI CRM supplier would
provide the Unstructured Data Transfer (UDT) ASE.
Both of these mechanisms provide a means of passing
application program encoded data to the partner.

2.Support for advanced encode/decode routines:
     A.. A method for linking to the application program -
          static or as a DLL.

     B.Access to the CPIC MAP_NAME variable.

     C.Ability to apply map routine to both data flowing
     through the normal send/receive services regular
     and initialization data.

     D.Management of map routines:
        1. Helping application designers locate useful
                   routines.
      2. Indexing what applications use a certain routine
                    so map routine  maintenance can be performed
                   easily.
     3. Use X.500 for management repository.

     E. The encoding methods, ASN.1 or proprietary, can be
                    supplied by third parties.